Querying one or more databases

ABSTRACT

A system and method for querying a database is disclosed. Database tables are represented as nodes in a model. Each node is associated with at least one leaf. The nodes can be interconnected with one another. A model input is received by a server from a client device, the model input including a starting node, one or more leaves, and optionally one or more filters. A query is executed against a database based on the model input. A subsequent query can be generated by selecting a result of the first query. Also disclosed is a technique for cancelling queries.

BACKGROUND

Many entities store data items on one or more databases. These databasesoften include tables with columns and rows. Each column in the table isassociated with a particular data field. Entries in the table areorganized in rows, with data corresponding to the entries stored in thecolumns for that particular row.

One problem often encountered with storing data in databases iseffectively querying the data. In some instances, the data for aparticular entity may be spread out across multiple database tables.When the data set is large and spread out across multiple databasetables, querying the data to return useful results can become acomplicated and daunting task. Additionally, since the relationshipbetween different database tables may not be readily understood by theperson generating the query, generating a query can be error-prone.

SUMMARY

One embodiment provides a method for querying one or more databases. Themethod includes: receiving, at a computing device, a selection of astarting node, wherein the starting node is included in a model thatcorresponds to one or more database tables; receiving, at the computingdevice, a selection of a first set of one or more leaves, wherein eachleaf is connected to a node in the model; generating a first databasequery based on the starting node and the first set of leaves; providinga first results output based on the first database query executing onthe one or more databases; receiving a selection of a result in thefirst results output; generating a second database query based on theselection of the result in the first results output, wherein the seconddatabase query is associated with a detail set associated with theresult; and providing a second results output based on the seconddatabase query executing on the one or more databases.

Another embodiment provides a method for generating a database query.The method comprises: generating five data sets to store database queryfragments; for each leaf in a first set, adding one or more databasequery fragments to one or more of the five data sets based on attributesof the leaf; and constructing the first database query by appendingtogether the database query fragments from the five data sets.

Yet another embodiment provides a system for generating a databasequery. The system includes: one or more databases; a client device; anda server. The server is configured to: receive a model input from theclient device over a data network, wherein the model input includes anode and a first set of leaves included in a model corresponding to oneor more database tables stored in the one or more databases; generate aplurality of data sets to store database query fragments; for each leafin the first set, add one or more database query fragments to one ormore of the plurality of data sets based on attributes of the leaf;construct a database query by appending together the database queryfragments from the plurality of data sets; execute the database queryagainst the one or more databases; and return results of the databasequery to the client device.

Yet another embodiment provides a server configured to: receive a modelinput from a client device over a data network, wherein the model inputincludes a node and a first set of leaves included in a modelcorresponding to one or more database tables stored in one or moredatabases; generate a plurality of data sets to store database queryfragments; for each leaf in the first set, add one or more databasequery fragments to one or more of the plurality of data sets based onattributes of the leaf; construct a database query by appending togetherthe database query fragments from the plurality of data sets; executethe database query against the one or more databases; and return resultsof the database query to the client device.

Yet another embodiment provides a method for querying a database. Themethod includes: receiving, at a server device, a query input from aclient device over a network connection; generating a database querybased on the query input; causing the database query to begin executingagainst one or more databases; determining whether a network connectionexists between the client device and the server device; and causing thedatabase query to be cancelled when the server determines that thenetwork connection does not exist between the client device and theserver device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example system for querying one or moredatabases, according to an example embodiment.

FIG. 2 is a block diagram of the arrangement of components of acomputing device configured to query one or more databases, according toan example embodiment.

FIG. 3 is a block diagram of example functional components for acomputing device, according to one embodiment.

FIG. 4 is a conceptual diagram of one or more database tables, accordingto an example embodiment.

FIG. 5 is a conceptual diagram illustrating a model including nodes andleaves that represents one or more database tables, according to anexample embodiment.

FIG. 6 is a conceptual diagram illustrating a model input for queryingone or more databases associated with the model in FIG. 5, according toan example embodiment.

FIG. 7 is a conceptual diagram illustrating a results output forquerying one or more databases associated with the model input of FIG.6, according to an example embodiment.

FIG. 8 is a conceptual diagram illustrating a model input for queryingone or more databases associated with the model in FIG. 5 by selecting aresult from the results output, according to an example embodiment.

FIG. 9 is a conceptual diagram illustrating a results output forquerying one or more databases associated with the model input of FIG. 6after selecting a result from a previous results output, according to anexample embodiment.

FIG. 10 is a conceptual diagram illustrating a model input for queryingone or more databases associated with the model in FIG. 5 by selecting aresult from the results output, according to an example embodiment.

FIG. 11 is a conceptual diagram illustrating a results output forquerying one or more databases associated with the model input of FIG.10 after selecting a result from a subsequent results output, accordingto an example embodiment.

FIG. 12 is a conceptual diagram illustrating a model including nodes andleaves that represents one or more database tables, according to anexample embodiment.

FIG. 13 is a conceptual diagram illustrating user interface forselecting a model input for querying one or more databases associatedwith the model in FIG. 12, according to an example embodiment.

FIG. 14 is a conceptual diagram illustrating a user interface fordisplaying a results output for querying one or more databasesassociated with the model input of FIG. 13 after selecting a result froma previous results output, according to an example embodiment.

FIG. 15 is a conceptual diagram illustrating yet another user interfacefor selecting a model input for querying one or more databasesassociated with the model in FIG. 12, according to an exampleembodiment.

FIG. 16 is a conceptual diagram illustrating a user interface fordisplaying a results output for querying one or more databasesassociated with the model input of FIG. 15 after selecting a result froma previous results output, according to an example embodiment.

FIG. 17 is a flow diagram for querying a database, according to anexample embodiment.

FIG. 18 is a flow diagram of method steps for generating a databasequery from a model input, according to an example embodiment.

FIG. 19 a conceptual diagram illustrating a model including a one nodeand a plurality of leaves, according to an example embodiment.

FIG. 20 a conceptual diagram illustrating a technique for canceling aquery, according to an example embodiment.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example system for querying one or moredatabases, according to an example embodiment. The system includes aclient device 102, a data network 104, one or more servers 106, anddatabases 108 and 110.

The client device 102 can be any type of computing device, including apersonal computer, laptop computer, mobile phone with computingcapabilities, or any other type of device. The client device 102includes, among other things, device hardware 120, a softwareapplication 122, other application(s), a communications client, outputdevices (e.g., a display), and input devices (e.g., keyboard, mouse,touch screen), etc. In some embodiments, a client device 102 may act asboth an output device and an input device.

Device hardware 120 includes physical computer components, such as aprocessor and memory. The software application 122 is configured toreceive input for querying the one or more databases 108, 110. Accordingto various embodiments, the software application 122 can be implementedin the OS (operating system) of the client device 102 or as astand-alone application installed on the client device 102. In oneembodiment, the software application 122 is a web browser application.

The data network 104 can be any type of communications network,including an Internet network (e.g., wide area network (WAN) or localarea network (LAN)), wired or wireless network, or mobile phone datanetwork, among others.

The client device 102 is configured to communicate with a server 106 viathe data network 104. The server 106 includes a software applicationexecuted by a processor that is configured to generate a query againstthe databases 108, 110 based on an input received from the client device102. The server 106 is in communication with databases 108 and 110. Thedatabases 108, 110 are configured to store data. The databases 108, 110can be any type of database, including relational databases,non-relational databases, file-based databases, and/or non-file-baseddatabases, among others.

As described in greater detail herein, one or more embodiments of thedisclosure provide a system and method for querying one or moredatabases. As described, databases are often organized as a series oftables. According to various embodiments, a database querying model canbe constructed as a series of interconnected “nodes,” where each nodecorresponds to a database table. Each node can be connected to zero ormore other nodes. Each node can also be associated with one or more“leaves,” where each leaf corresponds to one of the columns in thecorresponding database table. Each leaf can further be associated withan identifier, a “leaf type,” and zero or more detail parameters, asdescribed in greater detail herein.

A model input is generated based on a selection of a starting node, oneor more leaves, and zero or more filters at the client device 102. Themodel input is transmitted to the server 106 via the data network 104.The server 106 receives the model input and generates a database querybased on the model input. The database query is executed on the one ormore databases and returns results.

As stated, the model input includes selection of a single starting node,one or more leaves, and zero or more filters. The one or more leaves canbe leaves of the selected starting node and/or leaves of nodes that areconnected to the starting node. As described in greater detail herein,each leaf includes a leaf identifier, a leaf type, and optionally a“detail set,” among other things.

To generate the database query from the model input, the server 106executes a query generation algorithm, described in greater detail inFIG. 18. Namely, for each of the selected leaves, the server 106determines whether the leaf is reachable from the selected node by wayof interconnected nodes. If not, the leaf is ignored. Using the selectednode and set of reachable leaves, the computing device constructs aquery to retrieve data from the database(s). In addition, the server 106filters the set of data returned from the database(s), either directlywithin the generated database query, or after the database query hasreturned results. The query is then executed and results are returned.

To display the returned results, the computing device maps columns inthe results to the leaves of the model input. If a “detail set” isassociated with a particular leaf provided in the model input, thecomputing device also includes in the results the detail parameters forthe leaf for each row in the results.

FIG. 2 is a block diagram of the arrangement of components of acomputing device 200 configured to query one or more databases,according to an example embodiment. As shown, computing device 200includes a processor 202 and memory 204, among other components (notshown). In one embodiment, the computing device 200 comprises the clientdevice 102. In another embodiment, the computing device 200 comprisesthe server 106.

The memory 204 includes various applications that are executed byprocessor 202, including installed applications 210, an operating system208, and software application 222. In embodiments where the computingdevice 200 comprises the client device 102, the software application 222comprises a web browser application. In embodiments where the computingdevice 200 comprises the server 106, the software application 222comprises a software application configured to receive a model input andgenerate a database query.

FIG. 3 is a block diagram of example functional components for acomputing device 302, according to one embodiment. One particularexample of computing device 302 is illustrated. Many other embodimentsof the computing device 302 may be used. In one embodiment, thecomputing device 302 comprises the client device 102. In anotherembodiment, the computing device 302 comprises the server 106.

In the illustrated embodiment of FIG. 3, the computing device 302includes one or more processor(s) 311, memory 312, a network interface313, one or more storage devices 314, a power source 315, outputdevice(s) 360, and input device(s) 380. The computing device 302 alsoincludes an operating system 318 and a communications client 340 thatare executable by the client. Each of components 311, 312, 313, 314,315, 360, 380, 318, and 340 is interconnected physically,communicatively, and/or operatively for inter-component communicationsin any operative manner.

As illustrated, processor(s) 311 are configured to implementfunctionality and/or process instructions for execution within computingdevice 302. For example, processor(s) 311 execute instructions stored inmemory 312 or instructions stored on storage devices 314. Memory 312,which may be a non-transient, computer-readable storage medium, isconfigured to store information within computing device 302 duringoperation. In some embodiments, memory 312 includes a temporary memory,area for information not to be maintained when the computing device 302is turned OFF. Examples of such temporary memory include volatilememories such as random access memories (RAM), dynamic random accessmemories (DRAM), and static random access memories (SRAM). Memory 312maintains program instructions for execution by the processor(s) 311.

Storage devices 314 also include one or more non-transientcomputer-readable storage media. Storage devices 314 are generallyconfigured to store larger amounts of information than memory 312.Storage devices 314 may further be configured for long-term storage ofinformation. In some examples, storage devices 314 include non-volatilestorage elements. Non-limiting examples of non-volatile storage elementsinclude magnetic hard disks, optical discs, floppy discs, flashmemories, or forms of electrically programmable memories (EPROM) orelectrically erasable and programmable (EEPROM) memories.

The computing device 302 uses network interface 313 to communicate withexternal devices via one or more networks, such server 106 and/ordatabase 108 shown in FIG. 1. Network interface 313 may be a networkinterface card, such as an Ethernet card, an optical transceiver, aradio frequency transceiver, or any other type of device that can sendand receive information. Other non-limiting examples of networkinterfaces include wireless network interface, Bluetooth®, 3G and WiFi®radios in mobile computing devices, and USB (Universal Serial Bus). Insome embodiments, the computing device 302 uses network interface 313 towirelessly communicate with an external device, a mobile phone ofanother, or other networked computing device.

The computing device 302 includes one or more input devices 380. Inputdevices 380 are configured to receive input from a user through tactile,audio, video, or other sensing feedback. Non-limiting examples of inputdevices 380 include a presence-sensitive screen, a mouse, a keyboard, avoice responsive system, camera 302, a video recorder 304, a microphone306, a GPS module 308, or any other type of device for detecting acommand from a user or sensing the environment. In some examples, apresence-sensitive screen includes a touch-sensitive screen.

One or more output devices 360 are also included in computing device302. Output devices 360 are configured to provide output to a user usingtactile, audio, and/or video stimuli. Output devices 360 may include adisplay screen (part of the presence-sensitive screen), a sound card, avideo graphics adapter card, or any other type of device for convertinga signal into an appropriate form understandable to humans or machines.Additional examples of output device 360 include a speaker, a cathoderay tube (CRT) monitor, a liquid crystal display (LCD), or any othertype of device that can generate intelligible output to a user. In someembodiments, a device may act as both an input device and an outputdevice.

The computing device 302 includes one or more power sources 315 toprovide power to the computing device 302. Non-limiting examples ofpower source 315 include single-use power sources, rechargeable powersources, and/or power sources developed from nickel-cadmium,lithium-ion, or other suitable material.

The computing device 302 includes an operating system 318, such as theAndroid® operating system. The operating system 318 controls operationsof the components of the computing device 302. For example, theoperating system 318 facilitates the interaction of communicationsclient 340 with processors 311, memory 312, network interface 313,storage device(s) 314, input device 180, output device 160, and powersource 315.

As also illustrated in FIG. 3, the computing device 302 includescommunications client 340. Communications client 340 includescommunications module 345. Each of communications client 340 andcommunications module 345 includes program instructions and/or data thatare executable by the computing device 302. For example, in oneembodiment, communications module 345 includes instructions causing thecommunications client 340 executing on the computing device 302 toperform one or more of the operations and actions described in thepresent disclosure. In some embodiments, communications client 340and/or communications module 345 form a part of operating system 318executing on the computing device 302.

FIG. 4 is a conceptual diagram of one or more database tables 402, 404,406, according to an example embodiment. As shown, three database tablesare illustrated, tables 402, 404, 406. Table 402 represents “users” andincludes columns for name and email. Table 404 represents “orders” andincludes columns for date and user_id. Table 406 represents“order_items” and includes columns for order_id, item_name, and cost.The tables 402, 404, 406 may be stored in one or more databases. Asdescribed, according to various embodiments, the databases can berelational databases, non-relational databases, file-based databases,and/or non-file-based databases, among others. The tables shown in FIG.4 are merely examples used to illustrate embodiments of the disclosureand in no way limit the scope of the disclosure.

FIG. 5 is a conceptual diagram illustrating a model 500 including nodesand leaves that represents one or more database tables, according to anexample embodiment. As shown, the model 500 includes nodes 502, 504, 506and leaves 508, 510, 512, 514, 516. In one example, node 502 correspondsto table 402 in FIG. 4, node 504 corresponds to table 404 in FIG. 4, andnode 506 corresponds to table 406 in FIG. 4. Node 502 is connected tonode 504. Node 504 is also connected to node 506. The model 500 isrepresented by a model file. The nodes 502, 504, 506 are represented asseparate node files. Examples of a model file and node files areillustrated in Appendix A and are described in greater detail herein.

Node 502 is associated with leaf 508, node 504 is associated with leaves510, 512, and node 506 is associated with leaves 514, 516. Each leafincludes a leaf identifier and leaf type. Optionally, a leaf can alsoinclude a detail set. The leaf identifier is a character string thatuniquely identifies the leaf in the model 500. The leaf type correspondsto a data type of the data associated with the leaf. According to oneembodiment, the leaf type can be either a first type (also referred toherein as “Type I”) or a second type (also referred to herein as “TypeII”).

A Type I leaf, as used herein, is a leaf type, that when included in amodel input, groups the results so that entries with the same value forthat leaf are grouped into a single entry in the results. When more thanone Type I leaf are included in a model input, the results are groupedso that each row of the results table correspond to aggregated resultsthat have the same value for each tuple of the Type I leafs. A Type IIleaf, as used herein, is a leaf type, that when included in a modelinput, results in an aggregate function being applied to the query andreturned as a separate column in the results output. Examples of modelinputs with Type I and Type II leaves are provided below forillustration.

FIG. 6 is a conceptual diagram illustrating a model input 600 forquerying one or more databases associated with the model 500 in FIG. 5,according to an example embodiment. As shown, the model input 600includes selection of a starting node “C,” corresponding to node 506 inFIG. 5, and two leaves “V” and “X,” corresponding to leaves 508 and 512in FIG. 5, respectively.

FIG. 7 is a conceptual diagram illustrating a results output 700 forquerying one or more databases associated with the model input 600 ofFIG. 6, according to an example embodiment. As shown, the results output700 includes two rows, row 1 and row 2, and two columns 702, 704.

As described, the model input 600 includes a Type I leaf, leaf “V,”corresponding to leaf 508 in FIG. 5. The results of the query areaggregated so that each result that has the same value for leaf 508 isgrouped into a single row in the results output 700. In the exampleshown, the user with name “TJ” completed three orders (see, table 404 inFIG. 4). Each of the three orders completed by TJ is grouped into asingle row (i.e., row 2) in the results output 700. The aggregatedgroups for leaf 508 are shown in column 702 in the results output 700.

In addition, the model input 600 includes a Type II leaf, leaf “X,”corresponding to leaf 512 in FIG. 5. Leaf 512 is associated with a countof orders. In the results output 700, a numerical count is displayed incolumn 704 corresponding to the count of orders for each row. As shown,the rows are organized by users (i.e., by unique values of leaf 508) andcolumn 704 displays the order count for each user.

As an example, when the databases are relational databases that can bequeried by SQL (Structured Query Language) queries, the generated SQLquery based on the model input 600 may be:

SELECT users.name, COUNT(orders.id) FROM order_items LEFT JOIN orders ONorder_items.id=orders.id LEFT JOIN users ON orders.user_id=users.idWHERE users.name = “TJ” GROUP BY users.name

A more detailed explanation of how a server generates the above SQLquery based on the model input is described in greater detail below.

In some embodiments, the results output can be sorted based on certainleaves. For example, if the results output includes a “name” column, theresults output can be sorted by the name column. In one embodiment, analgorithm is used for determining the default sort order. For example,if the results output includes a column that represents a date or a timein the database, then a sort is performed by that field, descending. Ifno date or time is included in the results output, but one or morenumeric measures are included in the results output, then a sort isperformed by one of the numeric measures (e.g., the first one),descending. If no date or time or numeric measures are included in theresults output, the a sort is performed by the first field selected formodel input.

Also, in some embodiments, certain Type II leaves cannot be queried fromcertain starting nodes. Doing so may result in incorrect data by way ofimproper aggregation. The limitations on which leaves cannot be queriedfrom a certain starting node can be inferred based on the aggregatefunction used in the SQL fragment. For example, if the leaf uses a SUMaggregate function, the sum is only made available if the querying isfrom the starting node that the leaf is attached to, and not from adifferent node that joins that node with the starting node. For example,using an example of a model for flight information, if an “airports”node had a Type II leaf that calculated the sum of airports, this leafwould be available for model input when the model input starting node isthe airports node, but not when the model input node is another node,such as a flights node, even though the flights node is joined/connectedto the airports node.

As described in greater detail herein, a user of the database queryingsystem can “drill” further down into the results output by selecting aparticular result in the results output. Selecting a result generatesanother database query. For example, a user may select result 706corresponding to the number “3,” which represents the three ordersplaced by user TJ.

FIG. 8 is a conceptual diagram illustrating a model input 800 forquerying one or more databases associated with the model 500 in FIG. 5by selecting a result 706 from the results output 700, according to anexample embodiment. The model input 800 is generated based on the“detail set” of the selected leaf (i.e., leaf 512) in the column for theselected result 706. See FIG. 5, leaf 512, which is associated with adetail set identifying node C and leaves V, W, Y.

As shown, the model input 800 includes selection of a single node “C,”corresponding to node 506 in FIG. 5, three leaves “V,” “W,” and “Y,”corresponding to leaves 508, 510, and 514 in FIG. 5, respectively, and afilter for leaf “V” (i.e., leaf 508) with a value of “TJ.” Node 506 isselected as the starting node for the model input 800 based on thedetail set of the selected leaf (i.e., leaf 512). Leaves 508, 510, and514 are selected as the leaves of the model input 800 since leaves 508,510, and 514 are included in the “detail set” of the selected leaf(i.e., leaf 512). Also, the model input 800 is filtered by the valueseach of the Type I leaves corresponding to the selected row of theresult 706. In this example, result 706 is associated with row 2 of theresults output 700. Each row of the results output 700 is associatedwith one Type I leaf (i.e., leaf 508, corresponding to users.name). Themodel input 800 that is generated when the result 706 is selected for“drilling” is filtered by the value of the leaf 508 (i.e., in row 2 ofthe results output), in this example, having a value of “TJ.”

FIG. 9 is a conceptual diagram illustrating a results output 900 forquerying one or more databases associated with the model input 800 ofFIG. 8 after selecting a result 706 from a previous results output 700,according to an example embodiment. As shown, the results output 900includes two rows, row 1 and row 2, and three columns 902, 904, 906.

The model input 800 includes two Type I leaves, leaves V and W,corresponding to leaves 508 and 510, respectively, in FIG. 5. Theresults are aggregated so that each result that has the same value forboth leaves 508 and 510 is grouped into a single row in the resultsoutput 900. In the example shown, the user with name “TJ” completedthree orders (see, table 404 in FIG. 4). One of the orders was completedon 1/12/13 and two orders were completed on 2/2/13. As shown, the threeorders completed by TJ are grouped into two rows in the results output900 organized by each unique combination of users.name (i.e., column902) and orders.date (i.e., column 904). The aggregated groups for leaf508 are shown in column 702 in the results output 700.

In addition, the model input 800 includes one Type II leaf, leaf “Y,”corresponding to leaf 514 in FIG. 5. Leaf 514 is associated with a countof “order_items.id.” In the results output 900, a numerical count isdisplayed corresponding to the count of order items for each row. In theexample shown, one order was completed by TJ on 1/12/13 and two orderswere completed by TJ on 2/3/13, as shown in column 906.

As an example, when the databases are relational databases that can bequeried by SQL (Structured Query Language) queries, the generated SQLquery based on the model input 800 may be:

SELECT users.name, orders.date, COUNT(order_items.id) FROM order_itemsLEFT JOIN orders ON order_items.id=orders.id LEFT JOIN users ONorders.user_id=users.id WHERE users.name = “TJ” GROUP BY users.name,orders.date

As described, a user of the database querying system can “drill” downfurther into the results data by selecting a result in the resultsoutput 900, similar to drilling down into the results output 700 in FIG.7. Selecting a result generates another database query. For example, auser may select result 908 corresponding to the number “2,” whichrepresents the two orders placed by user TJ on 2/3/13.

FIG. 10 is a conceptual diagram illustrating a model input 1000 forquerying one or more databases associated with the model 500 in FIG. 5by selecting a result 908 from the results output 900, according to anexample embodiment. The model input 1000 is generated based on the“detail set” of the selected leaf (i.e., leaf 514) corresponding to thecolumn for the selected result 908. See FIG. 5, leaf 515, which isassociated with a detail set identifying node C and leaf Z.

As shown, the model input 1000 includes selection of a single node “C,”corresponding to node 506 in FIG. 5, one leaf “Z,” corresponding to leaf516 in FIG. 5, a filter for leaf “V” (i.e., leaf 508) with a value of“TJ,” and a filter for leaf “W” (i.e., leaf 510) with a value of“2/3/13.” Node 506 is selected as the starting node for the model input1000 based on the detail set of the selected leaf (i.e., leaf 514). Leaf510 is selected as a leaf of the model input 1000 since leaf 510 isincluded in the “detail set” of the selected leaf (i.e., leaf 514).Also, the model input 1000 is filtered by the values each of the Type Ileaves corresponding to the selected row of the result 908. In thisexample, result 908 is associated with row 2 of the results output 900.Each row of the results output 900 is associated with two Type I leaves,leaves 508 and 510, corresponding to users.name and orders.date,respectively. The model input 1000 that is generated when the result 908is selected for “drilling” is filtered by the value of the leaves 508and 510 in row 2 of the results output 908, i.e., having a values of“TJ” and “2/3/13,” respectively.

FIG. 11 is a conceptual diagram illustrating a results output 1100 forquerying one or more databases associated with the model input 1000 ofFIG. 10 after selecting a result 908 from a subsequent results output900, according to an example embodiment. As shown, the results output1100 includes two rows, row 1 and row 2, and one column 1100.

The model input 1000 includes one Type I leaf, leaf Z corresponding toleaf 516 in FIG. 5. The results are aggregated so that each result inthe results output 1100 that has the same value for leaf 516 is groupedinto a single row in the results output 1100. The results are alsofiltered by applying the two filters in the model input 1000. As shown,the two orders completed by TJ on 2/3/13 are grouped into two rows inthe results output 1100, organized by each unique item_name (i.e.,column 1102).

FIGS. 12-16 illustrate conceptual diagrams of another example model anda corresponding user interface for querying the model and returningresults.

FIG. 12 is a conceptual diagram illustrating a model 1200 includingnodes 1202, 1204, 1206, 1208 and leaves that represents one or moredatabase tables, according to an example embodiment. In this example,the model 1200 represents flight data organized by four database tablescorresponding to nodes for airports 1202, flights 1204, aircraft 1206,and accidents 1208. Each node is associated with a plurality of leaves.Some of the leaves are Type I leaves and some of the leaves are Type IIleaves. Also, the airports node 1202 is connected to the flights node1204, which is connected to the aircraft node 1206, which is connectedto the accidents node 1208.

FIG. 13 is a conceptual diagram illustrating user interface forselecting a model input for querying one or more databases associatedwith the model 1200 in FIG. 12, according to an example embodiment. Asshown, the airports node 1302 is selected as the starting node for themodel input. Selection of the starting node can be done via anytechnically feasible mechanism, including a drop-down list of availablestarting nodes. When the airports node 1302 is selected, a plurality ofleaves are displayed that can be selected for the model input.

In FIG. 13, leaves for AIRPORTS_state and AIRPORTS_count are selected. Aquery to the databases can be generated and executed by selecting thequery button 1308. The results of the query are shown in results output1310. The results output 1310 includes a column for each of the selectedleaves of the model input, i.e., leaves for AIRPORTS_state (column 1312in results output 1310) and AIRPORTS_count (column 1314 in resultsoutput 1310). In one example, AIRPORTS_state is a Type I leaf, so theresults in the results output 1310 are organized by grouping the resultsinto a separate row for each unique value of AIRPORTS_state. In thisexample, AIRPORTS_count is a Type II leaf, which calculates a count ofthe airports in each state.

As described herein, a user can further “drill” into the results output1314 by selecting a result. In one example, a user may select result1316, corresponding to the number “28” for the number of airports in thestate of RI (Rhode Island).

FIG. 14 is a conceptual diagram illustrating a user interface fordisplaying a results output 1400 for querying one or more databasesassociated with the model input of FIG. 13 after selecting a result 1314from a previous results output 1310, according to an example embodiment.The selected leaf from the previous results output 1310 (i.e.,AIRPORTS_count) is associated with a particular detail set. A modelinput is generated where the selected node corresponds to the nodeincluded in the detail set and the leaves of the model input are theleaves of the detail set. The results are filtered by the values of eachType I leaf in the row of the selected result (i.e., filter by theAIRPORT_state=RI).

As shown in FIG. 14, a subsequent results output 1400 is displayed thatincludes columns corresponding the leaves of the detail set of thepreviously selected result, filtered by the values of each Type I leafin the row of the selected result. Thus, the results output 1400displays the detail set for each of the 28 airports in RI.

FIG. 15 is a conceptual diagram illustrating yet another user interfacefor selecting a model input for querying one or more databasesassociated with the model 1200 in FIG. 12, according to an exampleembodiment. In FIG. 15, the flights node 1502 is selected as thestarting node. Selection of the starting node can be done via anytechnically feasible mechanism, including a drop-down list of availablestarting nodes. When the flights node 1502 is selected, a plurality ofleaves are displayed that can be selected for the model input.

Leaves for ORIGIN_state, DESTINATION_state, DESTINATION_city, andFLIGHT_count are selected for the model input. In FIG. 15, filters forFLIGHT_depart_date=01/01/2001, ORIGIN_state=CA, and DESTINATION_state=CAare also added to minimize the number of results for clarity.

A query to the databases can be generated and executed by selecting thequery button. The results of the query are shown in results output 1504.The results output 1504 includes a column for each of the selectedleaves of the model input, i.e., leaves for ORIGIN_state,DESTINATION_state, DESTINATION_city, and FLIGHT_count. In one example,each of ORIGIN_state, DESTINATION_state, and DESTINATION_city is a TypeI leaf, so the results in the results output 1504 are organized bygrouping the results into a separate row for each unique value-tripletof ORIGIN_state, DESTINATION_state, and DESTINATION_city. In thisexample, AIRPORTS_count is a Type II leaf, that calculates a count ofthe airports in each row of the results output.

As described herein, a user can further “drill” into the results output1504 by selecting a result. In one example, a user may select result1506, corresponding to the number “88” for the number of flights havingorigin state “CA” (California), destination state “CA,” and destinationcity “San Francisco.”

FIG. 16 is a conceptual diagram illustrating a user interface fordisplaying a results output 1600 for querying one or more databasesassociated with the model input of FIG. 15 after selecting a result 1506from a previous results output 1504, according to an example embodiment.The selected leaf from the previous results output 1504 (i.e.,FLIGHTS_count) is associated with a particular detail set. A model inputis generated where the selected node corresponds to the node included inthe detail set and the leaves of the model input are the leaves of thedetail set. The results are filtered by the values of each Type I leafin the row of the selected result 1506 (i.e., filter by origin state“CA,” destination state “CA,” and destination city “San Francisco”).

As shown in FIG. 16, a subsequent results output 1600 is displayed thatincludes columns corresponding the leaves of the detail set of thepreviously selected result 1506, filtered by the values of each Type Ileaf in the row of the selected result 1506. Thus, the results output1600 displays the detail set for each of the 88 flights that had adestination city of “San Francisco” that had an origin state “CA” anddestination state “CA.”

FIG. 17 is a flow diagram for querying a database, according to anexample embodiment. Persons skilled in the art will understand that eventhough the method 1700 is described in conjunction with the systems ofFIGS. 1-3, any system configured to perform the method stages is withinthe scope of embodiments of the disclosure.

As shown, the method 1700 begins at step 1702, where a server receives aselection of a starting node. In one embodiment, the server comprisesserver 106 in FIG. 1. The selection may be made via a user interfacedisplayed on a client device, such as client device 102, andcommunicated to the server over the data network 104. At step 1704, theserver receives a selection of one or more leaves. The starting node andthe one or more leaves may be received by the server as a “model input”associated with a model for one or more interconnected nodescorresponding to database tables.

At step 1706, the server generates database query based on the startingnode and the one or more leaves. Generating a the database query isdescribed in greater detail in FIG. 18.

At step 1708, a database returns results to the server and the serverreturns a results output to the client device. Each column of theresults output corresponds to one of the one or more selected leaves.Also, for each leaf that is a Type I leaf, the results are aggregated byunique values for each tuple of Type I leafs. For example, if there aretwo Type I leaves, the results are aggregated according to unique valuepairs for the two Type I leaves. Each aggregated tuple of Type I leavesis returned as a separate row of the results output. For each leaf thatis a Type II leaf, an aggregate calculation is performed and returnedfor each row of the results output.

At step 1710, the server receives a selection of a result from theresults output, also referred to herein as “drilling” on a returnedresult. In one embodiment, the selection is of a Type II result.

At step 1712, the server generates database query based on a detail setassociated with the selected result. As described, each Type II leaf maybe associated with a detail set that includes a starting node and one ormore leaves. A database query is generated using the starting node ofthe detail set and the one or more leaves of the detail set. Thedatabase query is also filtered by the values of each Type I leaf in therow of the selected result.

At step 1714, the server returns a subsequent results output. Eachcolumn of the results output corresponds to one of the leaves of thedetail set. Also, for each Type I leaf, the results are aggregated byunique values for each tuple of Type I leafs. Each aggregated tuple ofType I leaves is returned as a separate row of the subsequent resultsoutput. For each leaf that is a Type II leaf, an aggregate calculationis performed and returned for each row of the subsequent results output.

In this manner, a user can “drill” down into a returned results toreceive further refined data.

Model Creation and Model Files

As described, generating a database query is based on a model ofinterconnected nodes that have corresponding leaves. The model can bedefined by a model file that identifies the relationships between nodesin the model. An example of a model file is shown on page A1 of theAppendix to the specification.

The model may include one or more nodes. In an example of a model thatrepresents flight data, the model may include nodes of airports,aircraft, accidents, and flights. Each node is represented as a separatenode file. Examples of node files for airports, aircraft, accidents, andflights are shown in the Appendix (i.e., pages A2-A5 for an accidentnode file, pages A6-A8 for an aircraft node file, pages A9-A10 for anairports node file, and pages A11-A16 for a flights node file). In oneexample implementation, the model file and node files are implemented asfiles using the YAML (Yet Another Markup Language) syntax. In otherembodiments, a model can be stored in any format suitable for datastorage, for example, the model can be stored in a database.

In one implementation, the nodes in the model are referenced in themodel syntax using the terms “view” and “base_view.” Each view (i.e.,node) includes a set of leaves, joins, and sets. In one implementation,the leaves in the model are referenced in the model syntax using theterm “field.” The leaves can be of Type I or Type II. Type I leaves arealso referred to as “dimesions” and correspond to groupable fields thatcan be either an attribute of a database table (i.e., have some directphysical presence in a database table) or can be a computed from valuesin the database table. Type II leaves are also referred to as “measures”and corresponds to leaves implemented with an aggregate function, suchas COUNT( . . . ), SUM( . . . ), AVG( . . . ), MIN( . . . ) or MAX( . .. ), for example.

Joins define a connection between one node and other nodes. Sets definelists of leaves for a particular node. Example sets include:

-   -   ignore—the set of fields to ignore (not use in any context),    -   measures—the set of fields to use as measures,    -   base_only—the set of fields to be included in an base-view        context, and    -   admin—fields to include when the user has admin privileges.

As described in greater detail herein, the node and model files mayinclude query fragments used to generate a database query from a modelinput. In one implementation, the database query is an SQL (StructuredQuery Language) query and the query fragments are SQL fragments.

In some embodiments, if a leaf A can reach another leaf B in the model,leaf A can use a SQL fragment from leaf B as part of its own SQLfragment. FIG. 19 a conceptual diagram illustrating a model including aone node 1902 and a plurality of leaves 1904, 1906, 1908, 1910,according to an example embodiment. In this example, the syntax “$.{leaf identifier}” is used to reference two leaves (i.e., W and Y) in aSQL fragment 1912 of another leaf, i.e., leaf X. In one embodiment,including leaf X in a model input would result in the following SQLquery being generated:

-   -   SELECT users.city+“,”+users.state AS X FROM users GROUP BY X;

Similarly, selecting both leaves W and X in the model input would resultin the following SQL query being generated:

SELECT users.city AS W, users.city + “,” + users.state AS X FROM usersGROUP BY W,X;

This can be extended to any level of referencing of fields. For example,a field C can include SQL fragments from a field B, which includes SQLfragments from a field A. SQL fragment referencing in this manner canalso occur between Type I and Type II leaves, and from Type II to TypeII as well.

In addition, in some embodiments, some leaves can be automaticallypromoted to Type II from Type I. Knowing that a leaf can referencefragments from other leaves means that we can infer something about thetype of a leaf based on other leaves that are used to build the leaf. Inone implementation, when any leaf A is of Type II, any leaf B thatreferences leaf A can be inferred to also be of Type II. As described, aleaf that is of Type II uses an aggregate function and thereforeincludes the aggregation of a group of values for a given row in aresults output. As such, it is not possible to use a SQL fragment from aType II leaf in a Type I leaf, because the Type I leaves result in datafrom a single row in the data store. This means that we can infer,because a leaf B references a Type II leaf A, that leaf B is also a TypeII leaf.

One unique aspect of using models and associated nodes, as describedherein, is that data can be queried by selecting leaves from differentnodes for the model input. Different nodes can be interconnected usingthe following syntax and examples:

A node can be connected to another node with the ‘join’ statement.Appendix A, at page A12, line 53, is an example. The join statementdescribes the one-way connection from one node to another by using joinsyntax, where ‘join’ describes an identifier for the join (used todisplay fields names with the join identifier in front, such as(DESTINATION city), ‘from’ is a node identifier, and ‘sql_on’ is the sqlfragment required to join the node. The appendix example is morecomplex, because it employs another strategy we use to templateviews—‘$$’, which means the current node, in this case ‘airports’. Thissyntax allows us to join one node into another multiple times, but isnot required to describe a sql_on fragment. Optionally, a fields set canbe used to determine which fields should be accessible from the joinednode.

In addition, as described, each node can be associated with one or moreleaves. The leaves can be of Type I or Type II, as described. Also, a“detail set” can be associated with Type II leaves, such that asubsequent query is generated by selecting a particular Type II result(i.e., “drilling”).

In one embodiment, all leaves are Type I by default, and only becomeType II leaves when they are specified to be a subtype of Type II (suchas a count_distinct type, e.g., at page A9, line 26 of Appendix A), whenthey are placed into the ‘measures’ set (not shown in Appendix A), orwhen the SQL fragment references another Type II leaf (e.g., page A4,line 129). Detail sets are defined using the detail attribute on a leaf.The attribute can simply be an array of fields (not shown in AppendixA). An example would be ‘detail: [field1, field2, field3]’), or can be areference to another set defined elsewhere in the node (e.g., page A9,line 29 references page A9, line 8 as its detail set).

Query Generation from a Model Input

As described above in FIG. 17, i.e., at steps 1706 and 1712, a databasequery can be generated based on a selection of a starting node, one ormore leaves, and optionally one or more filters. Using SQL as example,the database query can be generated by executing the following stepsshown in FIG. 18.

In one implementation, node connections result in JOIN statements inSQL. In the model input, including leaves that are attached to nodesother than the starting node of the model implies that additional joinsare created in the generated SQL statement. This is accomplished byadding a SQL fragment for each node connection in the particular nodefile. An example is shown at page A12, line 53 of Appendix A. Here, weare joining the airport node into the flight node using the sql fragmentdescribed in the sql_on attribute, where $$ means the current node.

FIG. 18 is a flow diagram of method steps for generating a databasequery from a model input, according to an example embodiment. In thisexample embodiment, the generated query is a SQL query. Persons skilledin the art will understand that even though the method 1800 is describedin conjunction with the systems of FIGS. 1-3, any system configured toperform the method stages is within the scope of embodiments of thedisclosure.

As shown, the method 1800 begins at step 1802, where a server receives amodel input. In one embodiment, the server comprises server 106 inFIG. 1. The model input includes a starting node, one or more leaves,and optionally one or more filters. The selection of the starting node,the one or more leaves, and the optional one or more filters may be madevia a user interface displayed on a client device, such as client device102, and communicated to the server over the data network 104.

At step 1804, the server generates five (5) data sets to store SQLfragments. The data sets may correspond the following five SQL commands:SELECT, JOIN, WHERE, GROUP BY, and HAVING.

At step 1806, the server selects a leaf from the model input 1806. Atstep 1808, the server adds SQL fragment to one or more data sets basedon the leaf data. As described above, the leaf data may include variousinformation about the leaf, such as a leaf identifier, an indication ofwhether the leaf is a Type I leaf or a Type II leaf, a detail set forthe leaf, and/or an indication of nodes from which the leaf isaccessible.

In one example implementation, if the leaf is not reachable from thestarting node of the model input, then the leaf is ignored and themethod 1800 proceeds to step 1810. If the leaf is reachable from thestarting node, then the server adds the SQL fragment “{leaf SQLfragment} AS {leaf identifier}” to the SELECT data set. If the leaf is aType I leaf, then the server also adds “{leaf identifier}” to the GROUPBY data set. If the leaf is not connected to the staring node, butinstead is connected to another node, then the server adds the SQLfragment associated with the node connection in question to the JOINdata set with the following syntax: “LEFT JOIN {node identifier} ON{node connection SQL fragment}” to the JOIN data set. If the leaf has arequired_nodes attribute, then for each required_node node, the serveradds the SQL fragment associated with the node with the followingsyntax: “LEFT JOIN {node identifier} ON {node connection SQL fragment}”to the JOIN data set. In some embodiments, node dependency means thatleaves can include a new attribute (i.e., a set of nodes), referred toas “required_nodes.” When included as a leaf attribute, this attributespecifies that the SQL generated should include a join of the node thatthe SQL fragment needs in order to function properly.

At step 1810, the server determines whether any filters are included inthe model input. If no filters are applied, then the method 1800proceeds to step 1818. If filters are applied, then the method 1800proceeds to step 1812.

At step 1812, the server determines whether the leaf is Type I or TypeII. If the leaf is Type I, the method 1800 proceeds to step 1814. If theleaf is Type II, the method 1800 proceeds to step 1816.

At step 1814, for a Type I leaf, the server adds the leaf identifier tothe WHERE data set by adding the SQL fragment “{leaf identifier}={filtervalue}” to the WHERE data set. At step 1816, for a Type II leaf, theserver adds the leaf identifier to the HAVING data set by adding the SQLfragment “{leaf identifier}={filter value}” to the HAVING data set.

At step 1818, the server determines whether there are any more leaves inthe model input to process. If not, the method 1800 proceeds to step1820. If there are more leaves to process, then the method 1800 returnsto step 1806, described above.

At step 1820, the server constructs a SQL query with fragments from thefive data sets. In one embodiment, the server constructs the SQL queryby starting with a blank statement and performing the following steps:

-   -   appending “SELECT”+each value in the SELECT data set, comma        separated,    -   appending “FROM”+{node identifier},    -   appending each value in the JOIN data set,    -   appending “WHERE”+each value in the WHERE data set, comma        separated,    -   appending “GROUP BY”+each value in the GROUP BY data set, comma        separated,    -   appending “HAVING”+each value in the HAVING data set, comma        separated, and    -   appending a semicolon.

The server then executes the generated SQL query against the one or moredatabases. The results are returned as a result output, as describedabove.

Query Killing

One problem often encountered with database queries is that complicatedqueries can take a very long time to return results. Users can sometimesget frustrated with the long wait time and may close the query inputwindow on the client device. A new query input may then be input by theuser and a second database query is sent to the database.

However, in some cases, unbeknownst to the user, the first query maystill be executing against the database. This may cause the second queryto take a long time to return results, even if the second query issimple. One or more additional queries can be sent from one or moreusers, further clogging the database.

Embodiments of the disclosure provide a technique for automaticallycanceling certain queries, or “query killing.” FIG. 20 a conceptualdiagram illustrating a technique for canceling a query, according to anexample embodiment. As shown, a system 2000 includes a client 2002, aserver 2004, and a database 2006. The client 2002 is a softwareapplication for retrieving and displaying information from the server2004. The server executes also executes a software application, which isconfigured to construct a database query. The database 2006 is where thequery is executed.

In one embodiment, a request to execute a model query is transmitted bythe client 2002 to the server 2004 via a network connection. In someimplementations, a user in a browser application select a node and oneor more leaves as model input, selects for a query to be executed, andthen waits on a web page of the browser application for the resultsoutput to return from the database 2006. As described, some databasequeries, because of the nature of the data or the construction of thequery, require excessive processing power and/or memory to execute.Often these same queries result in reduced performance for otherconcurrent queries.

In one implementation, a method for canceling the query includes thesteps shown in FIG. 20. At step S1, the server 2004 receives a clientrequest for a model query over the network. This connection is held openas the client 2002 waits for the results. The server 2004 generates adatabase query and executes the query on the database 2006 (step S2 a)and retrieves in response a query identifier (step S2 b) correspondingto the query.

While the query is executing on the database 2006, the server 2004, atsome interval, checks for the existence of the network connection to theclient 2002 (step S3). In one implementation, non-blocking sockets maybe used. For example, the server 2004 performs a non-blocking read onthe client-server connection. If the non-blocking read fails, then thisindicates that the client 2002 is no longer listening for the responsefrom the database 2006. If the client connection check fails, then thisindicates that the client 2002 is no longer awaiting the response of themodel query (step S4). In one example, the user may have closed thebrowser page in the browser application. The server 2004 transmits a newcommand to the database 2006, causing the server 2006 to stop the queryusing the query identifier returned in step S2. Alternatively, if thequery completes and the client connection is still available, then theserver 2004 returns the results to the client 2002 in normal course.

Accordingly, embodiments of the disclosure create a 1-to-1 mappingbetween a network connection and an executing query. Some embodimentsrely on this connectivity to determine whether the query should becanceled. A closed socket implies that the query should not continueexecuting, which results in the cancelation of a query.

The use of the terms “a” and “an” and “the” and “at least one” andsimilar referents in the context of describing the disclosed subjectmatter (especially in the context of the following claims) are to beconstrued to cover both the singular and the plural, unless otherwiseindicated herein or clearly contradicted by context. The use of the term“at least one” followed by a list of one or more items (for example, “atleast one of A and B”) is to be construed to mean one item selected fromthe listed items (A or B) or any combination of two or more of thelisted items (A and B), unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein, and each separate value isincorporated into the specification as if it were individually recitedherein. All methods described herein can be performed in any suitableorder unless otherwise indicated herein or otherwise clearlycontradicted by context. The use of any and all examples, or examplelanguage (e.g., “such as”) provided herein, is intended merely to betterilluminate the disclosed subject matter and does not pose a limitationon the scope of the invention unless otherwise claimed. No language inthe specification should be construed as indicating any non-claimedelement as essential to the practice of the invention.

Variations of the embodiments disclosed herein may become apparent tothose of ordinary skill in the art upon reading the foregoingdescription. The inventors expect skilled artisans to employ suchvariations as appropriate, and the inventors intend for the invention tobe practiced otherwise than as specifically described herein.Accordingly, this invention includes all modifications and equivalentsof the subject matter recited in the claims appended hereto as permittedby applicable law. Moreover, any combination of the above-describedelements in all possible variations thereof is encompassed by theinvention unless otherwise indicated herein or otherwise clearlycontradicted by context.

1. A method for querying one or more databases, comprising: receiving,at a computing device, a selection of a starting node, wherein thestarting node is included in a model that corresponds to one or moredatabase tables; receiving, at the computing device, a selection of afirst set of one or more leaves, wherein each leaf is connected to anode in the model; generating a first database query based on thestarting node and the first set of leaves; providing a first resultsoutput based on the first database query executing on the one or moredatabases; receiving a selection of a result in the first resultsoutput; generating a second database query based on the selection of theresult in the first results output, wherein the second database query isassociated with a detail set associated with the result; and providing asecond results output based on the second database query executing onthe one or more databases.
 2. The method according to claim 1, whereinthe one or more databases are relational databases and the first andsecond database queries are SQL (Structured Query Language) queries. 3.The method according to claim 1, wherein each leaf in the first set ofleaves is associated with one of a first leaf type or a second leaftype.
 4. The method according to claim 3, wherein the first resultsoutput includes a column for each leaf in the first set and a separaterow for each unique tuple of values for leaves associated with the firstleaf type in the first set.
 5. The method according to claim 4, wherein,for each column in the first results output corresponding to a leafassociated with the second leaf type, an aggregate value is provided ineach row of the column based on data in the row.
 6. The method accordingto claim 5, wherein the aggregate value is based on computing a sum, acount, an average, a minimum, or a maximum of one or more values in therow.
 7. The method according to claim 1, wherein the model includes aplurality of interconnected nodes, wherein each node is associated withone or more leaves.
 8. The method according to claim 7, wherein eachleaf in the first set is associated with the starting node or anothernode in the plurality of interconnected nodes.
 9. The method accordingto claim 1, wherein generating the first database query comprises:generating five data sets to store database query fragments; for eachleaf in the first set, adding one or more database query fragments toone or more of the five data sets based on attributes of the leaf; andconstructing the first database query by appending together the databasequery fragments from the five data sets.
 10. The method according toclaim 1, wherein the first database query comprises an SQL (StructuredQuery Language) query, and the five data sets corresponds to SQLcommands for SELECT, JOIN, WHERE, GROUP BY, and HAVING.
 11. The methodaccording to claim 1, wherein the detail set associated with the resultis associated with a second starting node and a second set of leaves,wherein generating the second database query comprises generating thesecond database query based on the second starting node and the secondset of leaves, and wherein the second database query is filtered by oneor more values included in a row in the first results outputcorresponding to the selected result.
 12. The method according to claim1, wherein the one or more databases comprise relational databases,non-relational databases, file-based databases, and/or non-file-baseddatabases.
 13. The method according to claim 1, wherein the firstresults output is sorted according to one of the leaves in the firstset.
 14. A system for generating a database query, the systemcomprising: one or more databases; a client device; and a serverconfigured to: receive a model input from the client device over a datanetwork, wherein the model input includes a node and a first set ofleaves included in a model corresponding to one or more database tablesstored in the one or more databases; generate a plurality of data setsto store database query fragments; for each leaf in the first set, addone or more database query fragments to one or more of the plurality ofdata sets based on attributes of the leaf; construct a database query byappending together the database query fragments from the plurality ofdata sets; execute the database query against the one or more databases;and return results of the database query to the client device.
 15. Thesystem according to claim 14, wherein the database query comprises anSQL (Structured Query Language) query, and the plurality of data setscorresponds to the SQL commands for SELECT, JOIN, WHERE, GROUP BY, andHAVING.
 16. The system according to claim 15, wherein the leaf isassociated with a leaf SQL fragment and a leaf identifier, and whereinthe server is configured to add a SQL fragment to the SELECT data setusing the syntax “{leaf SQL fragment} AS {leaf identifier}” when theleaf is reachable from the node.
 17. The system according to claim 15,wherein the leaf is associated with a leaf identifier, and wherein theserver is configured to add a SQL fragment to the GROUP BY data setusing the syntax “{leaf identifier}” when the leaf is associated with afirst leaf type.
 18. The system according to claim 15, wherein the leafis associated with a leaf identifier and a node connection SQL fragment,and wherein the server is configured to add a SQL fragment to the JOINdata set using the syntax “LEFT JOIN {node identifier} ON {nodeconnection SQL fragment}” when the leaf is not connected to the node,but instead is connected to another node in the model, wherein the nodeconnection SQL fragment is associated with joining two nodes in themodel.
 19. A method for querying a database, comprising: receiving, at aserver device, a query input from a client device over a networkconnection; generating a database query based on the query input;causing the database query to begin executing against one or moredatabases; determining whether a network connection exists between theclient device and the server device; and causing the database query tobe cancelled when the server determines that the network connection doesnot exist between the client device and the server device.
 20. Themethod according to claim 19, wherein determining whether the networkconnection exists between the client device and the server devicecomprises performing a non-blocking read on the network connection.